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O (57) Abstract: The invention relates to a method for translating programmes into a system consisting of at least one first processor 
^ and a re-configurable unit. According to the method, parts of the code that are suitable for the re-configurable unit are determined 
and extracted and the remaining code is extracted in this manner for processing by the first processor. 
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(57) Zusammenfassung: Die Erfindung betrifft ein Verfahien zur Ubersetzung von Programmen auf ein System bestehend aus 
wenigstens einem ersten Prozessor und einer rekonfigurierbaren Einheit. Hierbei ist vorgesehen, dass die Codeteile, die fiir die 
rekonfigurierbare Einheit geeignet sind, bestimmt und extrahiert werden und der verbleibende Code zur Abarbeitung durch den 
ersten Prozessor derart extrahiert winl. 
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Titel: Verfahren zur Bearbeitung von Daten 

Beschreibung 

Die vorliegende Erfindung befaSt sich mit Datenverarbeitung. 
Insbesondere befajSt sich die vorliegende Erfindung mit her- 
kommlichen, d.h. konventionellen und rekonf igurierbaren Pro- 
zessorarchitekturen sowie mit Verfahren hierfiir, die eine 
Ubersetzung einer klassischen Hochsprache (PROGRAMM) wie 
Pascal, C, C++, Java, etc. ermoglichen, insbesondere auf eine 
rekonf igurierbare Architektur. Insbesondere befaSt sich die 
vorliegende Erfindung mit der Integration und/oder engen Kopp- 
lung von rekonf igurierbaren Prozessoren mit Standardprozesso- 
ren, dem Datenaustausch und der Synchronisation der Datenver- 
arbeitung. 

Unter einer konventionellen Prozessorarchitektur (PROZESSOR) 
werden vorliegend beispielsweise sequentielle Prozessoren mit ' 
einer von-Neumann- oder Harvardarchitektur verstanden., wie 
z.B. Kontroller, CISC-, RISC-, VLIW- , DSP-, u.t. Prozessoren 
verstanden . 



BESTATIGUNGSKOPIE 
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Unter einer rekonf igurierbaren Zielarchitektur warden vorlie- 
gend Bausteine (VPU) mit wiederholt und insbesondere zur Lauf- 
zeit insbesondere unterbrechungsf rei konf igurierbarer Funktion 
und/oder Vernetzung verstanden, insbesondere integrierte Bau- 
steine tnit einer Mehrzahl von ein- oder mehrdimensional ange- 
ordneten arithmetischen und/oder logischen und/oder analogen 
und/oder speichernden insbesondere evtl. auch grobgranularen 
Baugruppen (PAE) , die direkt oder durch ein Bussystetn mitein- 
ander verbunden sind. 

Zur Gattung dieser Bausteine zahlen insbesondere systolische 

Arrays, neuronale Netze, Mehrprozessor Systeme, Prozessoren 

mit mehreren Rechenwerken und/oder logischen Zellen, Veimet- 

zungs- und Netzwerkbausteine wie z.B. Crossbar-Schalter , eben- 

so wie bekannte Bausteine der Gattung FPGA, DPGA, XPUTER, 

etc. . Hingewiesen wird insbesondere in diesem Zusammenhang auf 

die folgenden Schutzrechte desselben Anmelders : P 44 16 881.0- 

53, DE 197 81 412.3, DE 197 81 483.2, DE 196 54 846.2-53, 

DE 196 54 593.5-53, DE 197 04 044.6-53, DE 198.80 129.7, 

DE 198 61 088.2-53, DE 199 80 312.9, PCT/DE 00/01869, DE 100 

36 627.9-33, DE 100 28 397.7, DE 101 10 530.4, DE 101 11 

014.6, PCT/EP 00/10516, EP 01 102 674.7, DE 196 51 075.9-53, 

DE 196 54 846.2-53, DE 196 54 593.5-53, DE 197 04 728.9, 

DE 197 07 872.2, DE 101 39 170.6, DE 199 26 538.0, 

DE 101 42 904.5, DE 101 10 530.4. Diese sind hiermit zu Offen- 

barungszwecken vollumf anglich eingegliedert . 

Das System kann insbesondere als (Standard) -Prozessor oder 
Baugruppe ausgestaltet sein und/oder in einem Halbleiter (Sy- 
stem on Chip SoC) integriert sein. 

Rekonf igurierbare Bausteine (VPUs) unterschiedlicher Gattungen 
(wie z.B. PACT XPP-Technologie, Morphics, Morphosys, Chamele- 
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on) sind zu bestehenden technischen Umgebungen und Program- 
mierverfahren weitgehend inkompatibel . 



Programme fur diese Bausteine sind typisch inkompatibel zu be- 
reits bestehenden Programmen von CPUs. Dadurch wird ein erheb- 
licher Entwicklungsauf wand zur Programmierung erf orderlich, 
z-B. besonders fur Bausteine der Gattungen Morphias, Morpho- 
sys. Chameleon integriert bereits einen Standardprozessor 
(ARC) auf mehr oder minder rekonf igurierbaren Bausteinen. Da- 
durch stehen Ansatze fur Tools zur Programmierung zur Verfii- 
gung. Allerdings ist nicht jede technische Umgebung fur den 
Einsatz von ARC-Prozessoren geeignet, insbesondere liegen be- 
stehende Programme, Codebibliotheken etc. oftmals fur beliebi- 
ge unbestimmte andere CPUs vor. 

Es hat sich in internen Versuchen gezeigt , daS es bestimmte 
Verfahren und Programmablauf e gibt, die sich besser mit einer 
rekonf igurierbare Architektur abarbeiten lassen als mit einer 
konventi one lien Prozessorarchitektur . Umgekehrt gibt es auch 
solche Verfahren und Programmablauf e, die besser mit einer 
konventionellen Prozessorarchitektur ausgefuhrt werden konnen. 
Es ist dafiir wxinschenswert , um eine jeweilige Optimierting zu 
ermoglichen, eine Ablauf teilung vorzusehen. 

Bekannte Ubersetzungsverf ahren fur rekonf igurierbare Architek- 
turen unterstutzen keine Weitergabe von Codes an beliebige 
Standard- Compiler zur Generierung von Objektcodes fiir einen 
beliebigen PROZESSOR. Gewohnlicherweise ist der PROZESSOR fest 
innerhalb des Compilers definiert- 

Weiterhin existieren keine Scheduling-Mechanismen zur Rekonfi- 

guration der einzelnen generierten Konf igurationen fur VPUs . 

Insbesondere fehlen Scheduling-Mechanismen fiir die Konfigura- 
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tion unabh^ngiger extrahierter Telle gleichwohl wie fiir ein- 
zelne Partitionen extrahierter Telle. Entsprechende Uberset- 
zungsverf ahren nach dem Stand der Technlk slnd belsplelswelse 
deflnlert durch die Dissertation „Ubersetzungsmethoden fiir 
strukturprogrammierbare Rechner, Dr. Markus Welnhardt, 1997^^. 

Zur Partltlonlerung von Array-CODE sind mehrere Verfahren nach 
dem Stand der Technlk bekannt, z. B. Joao M. P. Cardoso, „ Com- 
pilation of Java™ Algorithms onto Reconf igurable Computing Sy- 
stems with Exploitation of Operation -Level Parallelism", Ph. 
D. Thesis Universldade T€cnlca de Llsboa (UTL) , 2000. 

Diese Verfahren slnd jedoch in keine kompletten Compllersyste- 
me eingebettet . Welterhin setzen die Verfahren die vollst§.ndl- 
ge Steuerxing der Rekonf Iguration durch elnen Hostprozessor 
voraus, was elnen erheblichen Aufwand bedeutet . Die Partltlo- 
nierungsstrategien sind fiir FPGA-baslerende Systeme ausgelegt 
und entsprechen daher kelnera echten Prozessormodell . 

Die Aufgabe dieser Erfindung besteht darln, Neues fur die ge- 
werbllche Anwendung bereitzustellen. 

Die Losung dieser Aufgabe wird in unabhangiger Form bean- 
sprucht . Bevorzugte Ausfuhrungen finden sich in den Unteran- 
spriichen. 

Eln rekonf Igurierbarer Prozessor (VPU) wird somit in eine 
technlsche Umgebung eindeslgned, die. elnen Standardprozessor 
(CPU) besltzt, wie belsplelswelse elnen DSP, RISC, CISC- 
Prozessor oder (Mikro) -Kontroller aufweist . Das Design kann 
erf IndungsgemaS derart erfolgen, dass eine einfache und lei- 
stungsfahlge Anbindung besteht. Eln sich ergeb^nder Aspekt 1st 
die einfache Programmierbarkelt des entstehenden Systems . Die 
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Weiterverwendung bestehender Programme der CPU sowie die Code- 
kompatibilitat und die einfache Integration der VPU in die be- 
stehenden Programme finden Berucksichtigung. 

Eine VPU (oder ohne jeweils besonders erwahnt zu werden, meh- 
rere VPUs) wird derart mit einer bevorzugten CPU (oder ohne 
jeweils besonders erwahnt zu werden, mehreren CPUs) gekoppelt, 
dass sie die Stelle und Funktion eines Coprozessors (bzw. meh- 
rerer wahlweise ansprechbarer Coprozessoren) einnimmt. Die 
Funktion ermoglicht die einfache Einbindung in bestehende Pro- 
grammcodes entsprechend den bereits existierenden Methoden zum 
Umgang mit Coprozessoren nach dem Stand der Technik. 

Der erf indungsgemaSe Datenaustausch zwischen CPU und VPU kann 
mittels Speicherkopplung und/oder lO-Kopplung erfolgen. CPU 
und VPU konnen samtliche Ressourcen teilen, in besonderen Aus- 
gestaltungen ist es auch moglich, dass CPU und VPU nur einen 
Teil der Ressourcen gemeinsam verwenden und andere Ressourcen 
jeweils explizit und/oder exclusive fiir eine CPU oder VPU zur 
Verfugung stehen. 

Um einen Datenaustausch durchzufiihren, konnen Datensatze 
und/oder Konf igurationen in jeweils besonders dafiir vorgesehen 
Speicherbereiche kopiert bzw. geschrieben/gelesen werden 
und/oder entsprechende Basisadressen gesetzt werden, dass die- 
se auf die jeweiligen Datenbereiche zeigen. 

Zur Steuerung des Coprozessors wird bevprzugt ein Datensatz 

vorgesehen, der beispielsweise die Grundeinstellungen einer 

VPU beeinhaltet, wie beispielsweise bestimmte Basisadressen. 

Desweiteren konnen Statusvariablen zur Ansteuerung und Funkti- 

onssteuerung einer VPU durch eine CPU sowie fur Ruckmeldungen 

einer VPU an eine CPU vorgesehen sein. Der Datensatz kann uber 
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einen gemeinsamen Speicher (RAM) und/oder viber einen gemeinsa- 
men peripheren Adressraum (10) ausgetauscht werden. 



Zur Synchronisation der CPU und VPU konnen einseitig oder ge- 
genseitig wirkende Interruptverfahren (die z.B. durch Signal- 
transfer viber insbesondere dedizierte bzw. hierfur ausgebilde- 
te Interrupt lei tungen und/oder Interrupt eingange realisiert 
sind) vorgesehen sein und/oder die Synchronisation erfolgt 
mittels Pollingverfahren. Weiterhin konnen Interrupts zur Syn- 
chonisation von Daten- und/oder DMA-Transfers verwendet wer- 
den. 

In einer besonders zu bevorzugenden Ausgestaltung wird eine 
VPU durch eine CPU gestartet und arbeitet danach bevorzugt un- 
abhangig die Applikation ab. 

Besonders leistungsf ahig ist ein bevorzugter Aufbau, bei wel- 
chen die verwendete VPU eigene Mechanismen zum Laden und Kon- 
trollieren von Konf igurationen vorsieht . Zur Gattung dieser 
VPUs gehdren beispielsweise PACT XPP und Chameleon. Die erfin- 
dungsgemalSen Schaltungen ertnoglichen ein Verfahren zum Betrieb 
derart, dass die Konf igurationen der VPU zusammen mit dem aus- 
zufiihrenden Programm der CPU in einen Speicher geladen werden. 
Die CPU kann wahrend der Ausfiihrung des Programmes die VPU auf 
die Speicherstellen verweisen (z.B. durch Angabe der Adressen 
Oder Pointer) , die die jeweils auszuf uhrenden Konf igurationen 
beinhalten. Die VPU kann daraufhin die Konf igurationen selb- 
standig und ohne weitere EinfluSnahme durch die CPU laden. Die 
Ausfiihrung startet sofort oder ggf . durch eine. zusatzliche In- 
formation (z.B. Interrupt und/oder Start • Befehl) durch die 
CPU. 
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In einer besonders bevorzugten Erweiterung kann die VPU selb- 
stSndig innerhalb eines Speichers Daten lesen und schreiben. 



In einer besonders bevorzugten Erweiterung kann die VPU eben- 
falls selbstandig neue Konf igurationen aus dem Speicher laden 
und sich bei Bedarf neu konf igurieren, ohne dass es eines wei- 
teren Einflusses durch die CPU bedarf.. 

Diese Ausgestaltungen ermoglichen einen weitestgehend von CPUs 
unabhangigen Betrieb von VPUs. Lediglich ein Synchronisations- 
austausch zwischen CPU und VPU, der bevorzugt bidirektional 
stattfinden kann, sollte zusatzlich vorgesehen werden, urn die 
Datenverarbeitungen und/oder Konf igurationsausfuhrungen auf- 
einander abzustimmen. 

Es wurde weiter erkannt, dalS Verfahren zur Datenverarbeitung 
bevorzugt so ausgelegt werden konnen und/oder sollen, dafi je- 
weils fur die rekonf igurierbare Zielarchitektur (VPU) beson- 
ders geeignete Teile (VPU- CODE) des zu ubersetzenden Program- 
mes identif iziert und extrahiert werden, um eine besonders ef- 
fiziente Datenverarbeitung zu ermoglichen. Diese Teile sind 
entsprechend zu partitionieren und die Konf iguration der ein- 
zelnen Partitionen ist in ihrer zeitlichen Reihenfolge zu 
steuern. 

Die verbleibenden Teile des Programmes konnen auf eine konven- 
tionelle Prozessorarchitektur (PROZESSOR) iibersetzt werden. 
Dies geschieht bevorzugt dergestalt, dafi diese Teile als Hoch- 
sprachencode in einer Standard-Hochsprache (z. B. ANSI C) der- 
art ausgegeben wisrden, dafi ein gewohnlicher (ggf . bereits exi- 
stierender) Hochsprachencompiler diese ohne weiteres verarbei- 
ten kann. 
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Weiterhin sei angemerkt, daS die Verfahren auch auf Gruppen 
von tnehreren Bausteinen angewendet werden kSnnen. 



Insbesondere kann eine Art "Double-Buffering" zur besonders 
einfachen und zugleich schnellen Rekonf iguration angewendet 
werden, in welchem eine Mehrzahl von VPUs vorgesehen sind, wo- 
bei ein Teil der VPUs zu einer Zeit rekonf iguriert werden 
kann, zu welcher ein anderer Teil rechnet und moglicherweise 
ein Weiterer etwa inaktiv sein kann. Die Daten-, Trigger-, 
Statusverbindungen etc. werden zwischen der Mehrzahl von VPUs 
geeignet ausgetauscht und ggf . durch adressierte Busse 
und/oder Multiplexer/Demultiplexer entsprechend der aktuell 
aktiven und/oder zu rekonf igurierenden VPUs verschaltet. 

Ein Vorteil dieses Verfahrens liegt darin, dafi bestehender 
Code, der fiir einen beliebigen PROZESSOR geschrieben wurde, 
unter Einbeziehung einer VPU weiterverwendet werden kann und 
keine oder nur vergleichsweise geringe Modif ikationen durchge- 
fuhrt werden mussen. Die Modif ikationen konnen zudem schritt- 
weise erfolgen, wobei nach und nach immer mehr Code von dem 
PROZESSOR auf die VPU ubertragen werden kann. Das Projektrisi- 
ko sinkt und die Uberschaiibarkeit steigt wesentlich an. Es 
wird darauf hingewiesen, daS einer derartigen sukzessive Uber- 
tragung von immer mehr Aufgaben auf die VPU, d.h. auf das in- 
tegrale multidimensionale partiell rekonf igurierbaren insbe- 
sondere grobgranulare Feld an Elementen, eine besondere Bedeu- 
tung fur sich hat und fur sich als erfinderisch angesehen wird 
aufgrund seiner gravierenden Vorteile bei der Systemportie- 
rung. 

Weiterhin kann der Programmierer in seiner gewohnten Entwick- 
lungsumgebung arbeiten und muS sich nicht auf eine neue, mog- 
licherweise fremde Entwicklungsumgebung einstellen. 
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Ein erster wesentlicher Aspekt der vorliegenden Erfindung ist 
darin zu sehen, daS ein PROZESSOR derart mit einer oder mehre-. 
ren VPU(s) verbunden wird, daS ein effizienter Inf ormations- 
austausch, insbesondere in Form von Daten- und Statusinf ortna- 
tion moglich ist. 

Der Anordnung eines herkommlichen Prozessors und eines rekon- 
f igurierbaren Prozessors, dergestalt, daE ein Austausch von 
Daten- und/oder Statusinf ormat ion zwischen denselben wahrend 
der Abarbeitung eines oder mehrerer Programme moglich ist 
und/oder ohne daS insbesondere die Datenverarbeitung auf dera 
rekonf igurierbaren Prozessor und/oder dem herkommlichen Pro- 
zessor signifikant unterbrochen werden mufi, sowie der Ausbil- 
dung eines derartigen Systems, wird gleichfalls fur sich Be- 
deutung zugemessen. 

Es konnen zunachst beispielsweise eines oder alle der folgen- 
den Verbindungsverf ahren und/oder -mittel verwendet werden: 

a) Shared-Memory 

b) Netzwerk (beispielsweise Bussysteme wie z.B. PCI-Bus, Se- 
rielle Busse wie z.B. Ethernet) 

c) Kopplung an einen internen Registersatz oder mehrere in- 
teren Registersatze 

d) andere Speichermedien (Festplatte, Flash-ROM, etc.) 

Prinzipiell kann auch die VPU und/oder CPU selbstandig ohne 
Zuhilfenahme eines DMAs auf den Speicher zugreifen. Der ge- 
meinsame Speicher kann insbesondere auch als Dualport- oder 
Multiportspeicher ausgestaltet sein. Dem System konnen weitere 
Baugruppen zugeordnet werden, insbesondere konnen rekonf igu- 
rierbare FPGAs eingesetzt werden, urn eine f eingranulare Verar- 
beitung von einzelner Signale oder Datenbits zu ermoglichen 

9 



wo 02/103532 PCT/EP02/06865 

und/oder flexible adapt ierbare Interface (z.B. diverse seriel- 
le Schnittstellen (V24, USB, etc.), diverse parallele Schnitt- 
stellen, Festplattenschnittstellen, Ethernet, Telekommunikati- 
onsschnittstellen (a/b, TO, ISDN, DSL, etc)) aufbauen zu kon- 
nen. 

Der Aufbau einer VPU ist beispielsweise bekannt aus den o. g. 
zitierten Anmeldungen. Versuche zu alternativen Bausteindef i- 
nitionen sind beispielsweise unter dem Namen Chameleon gefiihrt 
worden. VPUs lassen sich auf unterschiedliche Weise in ein Sy- 
stem integrieren. Ein AnschluS an einen Hostprozessor ist bei- 
spielsweise moglich. Je nach Verfahren kann der Hostprozessor 
die Konf igurationskontrolle (HOSTRECONF) mit ubernehmen (z. B. 
Chameleon) oder, z. B., eine dedizierte Einheit (CT) zur 
Steuerving der (Re) Konf iguration bestehen. 

Entsprechend generiert der Ubersetzer gemaS dem beschriebenen 
Verfahren die Steuerinf ormation fur die Rekonf iguration fiir 
eine CT und/oder einen HOSTRECONF. 

Es kann nun das Ubersetzungsprinzip derart ausgestaltet sein, 
daS aus einem PROGRAMM mittels eines PRAPROZESSORS die Telle 
extrahiert werden, die sich auf die jeweils bestimmte(n) 
VPU(s) effizient und/oder sinnvoll abbilden lassen. Diese Tei- 
le werden in ein fur VPUs geeignetes Foirmat transf ormiert 
(NML) und dann weiter in einen Objektcode vibersetzt. 

Der verbleibenden Code und/oder der extrahierte Code wird er- 

fahrungsgemaS an oder beziiglich der Stelle der durch die Ex- 

traktion fehlenden Code-Teile um einen Interface -Code erwei- 

tert, der entsprechend der Architektur des Zielsystems die 

Kommunikation zwischen PROZESSOR (en) und VPU(s) steuert. Der 

verbleibende und ggf . erweiterte Code kann bevorzugt 
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trahiert werden sollen. Beispielsweise kann dies f olgenderma- 
Sen erfolgen: 



Code 

# START_EXTRACTION 

Zu extrahierender Code 

# END_EXTRACTION 

Code 

„// START_EXTRACTION" kennzeichnet den Beginn eines zu extra- 
hierenden Codes. 

„// END_EXTRACTION" kennzeichnet das Ende eines zu. extrahie- 
renden Code . 

In einem solchen Fall ist die Einheit zur Umsetzung des Pro- 
gramms in Konf igurationscodes dazu ausgebildet, die Hints be- 
ziehungsweise Umsetzungsvorgaben zu erkennen. 

Es ist auch moglich, dafi zur Extraktion durch Aufruf von NML- 
Routinen Telle des PROGRAMMES direkt in NML implementiert wer- 
den und in die NML-rRoutinen durch Aufrufe (calls) gesprungen 
wird. Beispielsweise erfolgt dies derart : 

a) NML -Code 

procedure EXAMPLE 
begin 

end 
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b) PROGRAMM Code 
Code 

call EXAMPLE // Aufruf des NML-Codes 

Code 

In diesem Fall ist die Einheit zur Umsetzung dazu ausgebildet, 
NML-Programmteile, das heiSt Programmteile zur Ausfuhrung in 
und/oder auf einem rekonf igurierbaren Array in ein groSeres 
Programm einzubinden. 

Es ist waiter alternativ und/oder zusatzlich eine Extraktion 
aus einer objektorientierten Klasse mdglich. Fiir eine VPU ge- 
eignete Makros werden als Klasse in der Klassenhierarchie ei- 
ner objektorientierten Programmiersprache def iniert . Die Ma- 
kros konnen daibei. durch Annotation derart gekennzeichnet sein, 
daS sie als fur eine VPU bestimmte Codes erkannt und entspre- 
chend - auch in hpheren Hierarchien der Sprache - weiterverar- 
beitet werden. 

Innerhalb eines Makros ist bevorzugt eine bestimmte Vernetzung 
und/oder Abbildung durch das Makro vorgegeben, die sodann die 
Abbildung des Makros auf die VPU bestimmt. 

Durch die Instantiierung und Verkettung der Klasse entsteht 
eine Implementierung der Funktion, bestehend aus mehreren Ma- 
kros auf der VPU. Mit anderen Worten definiert die Instantiie- 
rung und Verkettung der Makros die Abbildung und Vernetzung 
der einzelnen Operationen aller Makros auf der VPU und/oder 
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ggf . die Vernetzung \ind/ocler den Datenaustausch zwischen vpu 
und CPU. 

Die Interf acecodes warden bei der Instant iierung hinzugefugt . 
Die Verkettung beschreibt das detaillierte Mapping der Klasse 
auf die VPU. 

Eine Klasse kann beispielsweise auch als ein Aufruf einer oder 
mehrerer NML-Routinen gebildet werden. 

a) Klas sen- Code 

class EXAMPLE 
begin 

end 

b) PROGRAMM Code 
Code 

EXAMPLE varO // Instantiierxing der Klasse 

Code 

Es ist weiter auch eine Extraktion durch Analyse moglich. 
Durch an die jeweilige VPU angepaSte Analysemethoden werden 
Telle innerhalb des PROGRAMMES erkannt, die effizient und/oder 
sinnvoll auf die VPU abbildbar sind. 
Diese Telle werden aus dem PROGRAMM extrahiert . 
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Eine beispielsweise fur viele VPUs geeignete Analysemethode 
ist der Aufbau von DatenflulS- und/oder Kontrollf luSgraphen aus 
dem PROGRAMM. Diese Graphen konnen hinsichtlich ihrer mogli- 
chen Partitionierung und/oder Abbildung auf die Ziel-VPU auto- 
mat isch untersucht werden. In diesem Fall warden die Teile der 
generierten Graphen bzw. die entsprechenden PROGRAMMTEILE, ex- 
trahiert, die sich hinreichend gut partitionieren und/oder ab- 
bilden lassen. Hierzu kann eine Partitionierbarkeits- und/oder 
Abbildbarkeitsanalyse erfolgen, die die jeweilige Eigenschaft 
bewertet Entsprechend dieser Bewertung erfolgt dann die Parti- 
tionierung und Extraktion der Programmteile auf die VPU, sowie 
das Einf uhren der vorgesehenen Interfaces . . 

Es soli ausdriicklich auf die in der Patentanmeldung DE 101 39 
170.6 beschriebenen Analysemethoden verwiesen werden, die bei- 
spielsweise zur Anwendung kommen konnen- Die vorerwahnte An- 
meldung ist zu Of f enlegungszweckung vollumf anglich eingeglie- 
dert . 

Eine mogliche Analysemethode ist auch durch Erkennung bestimm- 
ter Datentypen gegeben. 

Unterschiedliche Datentypen eignen sich mehr oder weniger cfut 
fur die Bearbeitung auf einer VPU. Beispielsweise ist eine 
koraplexe Pointer-Arithmetik, bzw. eine pointerbasierende Da- 
tenadressierung (pointer) schwer auf eine VPU abbildbar, wah- 
rend sich Arrays (array) sehr gut abbilden lassen.. 

Erf indungsgemalS konnen daher weitgehend automat isch oder manu- 
ell die jeweils geeigneten Datentypen und zumindest wesentli- 
che Teile von deren Datenverarbeitung auf eine VPU ubertragen 
und entsprechend extrahiert werden. Die Extraktion erfolgt da- 
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mit im Ansprechen auf das Auftreten bestitnmter Datentypen 
und/oder Datenoperationen. 



Es soil erwahnt werden, daS zusatzliche, den Datentypen zuge- 
ordnete Parameter weitere Hinweise zur Bestimmung der Ausfuhr- 
barkeit und/oder Ausf uhrungsperf ormance auf einer VPU geben 
konnen und daher maSgeblich zur Extraktion tnitverwendet werden 
konnen. Beispielsweise spielt die GroSe von zu berechnenden 
Arrays eine wesentliche Rolle. Es lohnt sich zumeist nicht, 
kleine Arrays auf einer VPU zu berechnen, da hier der Synchro- 
nisations- und Datenaustauschaufwand zwischen CPU und VPU zu 
hoch sein kann. Einschrankend ist aber dabei wiederum zu er- 
wahnen, daS kleine Arrays, die innerhalb einer Schleife beson- 
ders haufig verrechnet werden, sich dennoch sehr gut fiir VPUs 
eignen, insofern die Schleife weitestgehend komplett auf der 
VPU berechnet wird. GroSe Arrays k6nnen dagegen zumeist ohne 
weiteres auf einer VPU besonders performant berechnet werden. 

Weiterhin soil erwahnt werden, dalS besondere Datentypen durch 
einen besonders angepaSten Compiler oder ggf . durch einen An- 
wender (z. B. mittels TYPE in Pascal) erstellt werden konnen, 
die sich besonders fvir VPUs eignen und deren Datenverarbeitung 
dann auf einer VPU ausgefiihrt wird. 

Beispielsweise konnen folgende Datentypen bestehen: 
TYPE streaml of Byte [] ; 
TYPE stream2 of Byte [0..255; 

Stream definiert einen Datenstrom (stream) von in der Kegel 
groSer,. ggf. nicht vorbekannter und/oder unendlicher LSnge. 
Streaml hatte hier eine nicht vorbekannte Lange. Beispielswei- 
se konnte ein mit diesem Datentyp programmierter FIR-Filter 
(Oder z. B. eine FFT oder DCT) automatisch - und ggf ausge- 

walzt - auf eine VPU abgebildet werden. Die Rekonf iguration 
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erfolgt dann typisch und bevorzugt im Ansprechen auf andere 
Mechanismen als den Datenstromverlauf , z.b. durch Zahler, Ver- 
gleicher, CT-gesteuert und/oder durch Time-Out. Soli hierbei 
etwa eine Wave- oder andere Rekonf iguration ausgel6st werden, 
so kann diese iiber eine durch vorgenannte Methoden veranlaSte 
Kennzeichnung eines Datenpaketes, insbesondere Datenbytes, als 
ein letztes zu sein erfolgen um nach uhd/oder mit dem Durch- 
lauf dieses als letzes Datenpaket gekennzeichneten Datenpake- 
tes die Rekonf iguration auszulosen. 

stream2 definiert einen Datenstrom der Lange von hier 256 
Byte, der wie streaml behandelt werden kann, jedoch die Eigen- 
schaft aufweist, nach 256 Byte zu enden und damit nach Beendi- 
gung moglicherweise eine Rekonf iguration im Sinne der vorab 
zitierten Patente selbigen Anmelders auslosen kann. Insbeson- 
dere kann eine Wave -Rekonf iguration (z. B. nach DE 197 04 
728.9, DE 199 26 538.0, DE 102 06 857.7, DE 100 28 397.7) mit 
dem Eintreffen des letzten Daten-Bytes ausgelost werden und 
mit der Verarbeitung dieses letzten Daten-Bytes die jeweilige, 
das Byte verarbeitende PAE rekonf iguriert werden. 

Eine fur die implementierte VPU geeignete Ubersetzung des ex- 
trahierten Codes nach NML kann bevorzugt durchgefuhrt werden. 

Fiir datenf luSorientierte VPUs kann beispielsweise automatisch 
ein Datenf luS- und/oder Kontrollf luSgraph aufgebaut werden. 
Die Graphen werden dann in NML-Code ubersetzt . 

Entsprechende Code-Teile wie z. B. Schleifen konnen mittels 

einer Datenbank (Lookup) ubersetzt werden oder gewohnliche 

Trans formationen konnen durchgefuhrt werden. Fvir Codeteile 

konnen auch Makros vorgesehen sein, die dann geraaS den in vor- 

genannten Anmeldungen offenbarten IKR weiterverwendet werden. 
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Ebenfalls kann die Modular! sierung nach PACT13, Fig. 28 unter- 
stutzt werden. 

Gegebenenfalls kann bereits das Abbilden auf die VPU bzw. des- 
sen Vorbereitung erfolgen, beispielsweise mittels der Durch- 
fiihrung des Plazierens der bendtigten Ressourcen und des Rou- 
tens der Verbindungen (Place and Route) . Dies kann zum Bei- 
spiel nach per se bekannten Regain des Plazierens und Routens 
geschehen . 

Es ist auch moglich, mittels einer automatischen Analysemetho- 
de den extrahierten Code und/oder den iibersetzten NML-Code auf 
seine Verarbeitungsef f izienz hin zu analysieren. Dabei ist die 
Analysemethode bevorzugt so gewahlt, daS der Interface-Code 
und die daraus entstehenden Perf ormanceeinf lusse an geeigneter 
Stelle mit in die Analyse einflieSen. Geeignete Analyseverf ah- 
ren sind insbesondere in den vorgenannten Anmeldungen der vor- 
liegenden Anmelderin beschrieben. 

Gegebenenfalls wird die T^alyse durch eine komplette Uberset- 
zung und Imp lementie rung auf dem Hardware -System durchgef uhrt , 
indem das PROGRAMM ausgefiihrt und mit geeigneten Methoden, wie 
sie beispielsweise nach dem Stand der Technik bekannt sind, 
vermessen wird. 

Es ist weiter raoglich, daS basierend auf den durchgef uhrten 
Analysen, verschiedene durch die Extraktion fur eine VPU ge- 
wahlte Telle als ungeeignet identif iziert werden konnen. Umge- 
kehrt kann die Analyse ergeben, dafi bestimmte, fur einen PRO- 
2ESSOR extrahierte Telle zur Ausfiihrung auf einer VPU geeignet 
waren . 
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Eine optionale Schleife, die nach der Analyse basierend auf 
geeigneten Entscheidungskriterien zuruck in den Extraktions- 
teil fuhrt, um diesen rait entsprechend der Analyse angepaBten 
Ext rakt ions vorgaben erneut auszufiihren, ermoglicht die Opti- 
raierung des Ubersetzungsergebnisses . Man hat somit eine Itera- 
tion. Dieses Vorgehen ist bevorzugt. 

Eine Schleife kann an mehreren unterschiedlichen Stellen in 
den Compilerlauf eingebracht sein. 

Der erhaltene NML-Code ist bei Bedarf entsprechend den Eigen- 
schaften der verwendeten VPU zu partitionieren, d.h. in ein- 
zelne Telle zu zerlegen, die auf jeweils in die vorhandenen 
Ressourcen abgebildet werden konnen. 

Eine Vielzahl derartiger Mechanismen, insbesondere auf Gra- 
phenanalyse basierende, sind nach dem Stand der Technik per se 
bekannt. Eine bevorzugte Variante basiert jedoch auf der Ana- 
lyse der Programmsourcen und ist unter dem Begriff temporal 
Partitioning bekannt. Dieses Verfahren ist in der genannten 
PHD-Thesis von Cardoso beschrieben, die zu Of f enbarungszwecken 
vollumfSnglich eingegliedert wird. 

Partitionierungsverf ahren gleich welcher Art sind entsprechend 

des verwendeten VPU-Types zu adapt ieren. Liegen VPUs vor, die 

die Speicherung von Zwischenergebnissen in Register und/oder 

Speicher zulassen, ist durch die Partitionierung die Einbin- 

dung der Speicher zur Speicherung von Daten und/oder Zustanden 

zu berucksichtigen. Die Partitionierungsalgorithmen (z. B. die 

temporale Partitionierung) sind entsprechend zu adaptieren. 

Gewohnlicherweise wird die eigentliche Partitionierung und das 

Scheduling durch die genannten Patente jedoch erheblich ver- 

einfacht und erst sinnvoll ermoglicht. 
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Manche VPUs bieten die Moglichkeit der dif f erentiellen Rekon- 
figuration. Diese kann angewendet warden, wenn nur verhaltnis- 
mafiig wenige Anderungen innerhalb der Anordnung der PAEs bei 
einer Rekonf iguration notwendig werden. Mit anderen Worten 
werden nur die Veranderungen einer Konf iguration gegeniiber der 
aktuellen Konf iguration rekonf iguriert . Die Partitionierung 
kann in diesetn Fall dergestalt sein, daC die auf eine Konf igu- 
ration folgende, gegebenenf alls dif f erentielle Konf iguration 
nur die notwendigen Rekonf igurationsdaten enthalt und keine 
vollstandige Konf iguration darstellt. Es ist moglich, den Kon- 
f igurationsdatenoverhead zu Analysezwecken bei der Beurteilung 
der Auf teilungsef f izient mit zu beriicksichtigen . 

Die Schedulingmechanismen fur die partitionierten Codes konnen 
derart erweitert werden, daS das Scheduling durch Ruckmeldxan- 
gen der VPU an die jeweils rekonf igurierende Einheit (CT 
und/oder HOSTRECONF) gesteuert wird. Insbesondere wird dabei 
bei der Partitionierung die sich daraus ergebende Moglichkeit 
der bedingten Ausfvihrung, d. h. der expliziten Bestimmung der 
nachf olgenden Partition durch den Zustand der aktuellen Parti- 
tion genutzt. Mit anderen Worten ist es moglich, die Partitio- 
nierung derart zu optimieren, dafi bedingte Ausfiihrungen wie z. 
B. IF, CASE etc. berucksichtigt werden. 

Werden VPUs verwendet, die die Fahigkeit besitzen Statussigna- 
le zwischen den PAEs zu ubertragen, wobei PAEs auf die je^^^^s 
iibertragenen Zustande reagieren und/oder diese mitverarbeiten, 
kann innerhalb der Partitionierung und des Schedulings zudem 
die bedingte Ausfuhrung innerhalb der Anordnung der PAEs, also 
ohne die Notwendigkeit einer vollst^ndigen oder teilweisen Re- 
konf iguration aufgrund eines geanderten bedingten Pro- 

grammablauf s, berucksichtigt werden. 
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Weiterhin kann das Scheduling die Moglichkeit des Vorladens 
von Konf igurationen wahrend der Laufzeit einer anderen Konfi- 
guration unterstiitzen. Dabei konnen mehrere Konf igurationen 
tnoglicherweise auch spekulativ vorgeladen werden, d. h. ohne 
daS sichergestellt ist, daS die Konf igurationen iiberhaupt be- 
not igt werden. Durch Selektionsmechanismen konnen dann zur 
Laufzeit die zu verwendenden Konf igurationen ausgewahlt werden 
(siehe auch Beispiel NLS in DE 100 50 442.6, EP 01 102 674.7) 

Eine zus^tzliche oder alternative Variante sieht vor, dass die 
Datenverarbeitung innerhalb der an die CPU gekoppelten VPU ex- 
akt gleichviele Takte benotigt, wie die Datenverarbeitung in- 
nerhalb der Rechenpipeline der CPU. Insbesondere bei modernen 
Hochleistungs-CPUs mit einer Vielzahl von Pipelinestuf en (>20) 
kann dieses Konzept ideal eingesetzt werden. Der besondere 
Vorteil ist, dass keine besonderen Synchronisationsmechanismen 
wie z.B. RDY/ACK notwendig sind und/oder keine Anpassung von 
Opcodes zur Registersteuerung erforderlich ist. Der Compiler 
hat bei diesem Verfahren sicherzustellen, dass die VPU die er- 
f orderliche Anzahl an Takten einhalt und ggf . die Datenverar- 
beitung durch das Einfvigen von Verzdgerungsstuf en wie z. B. 
einen Fall -Through FIFOs auszubalancieren wie er in anderen, 
vorerwShnten Anmeldungen beschrieben ist . 

Der ausgegebene Code ist iiblicherweise vollstandig und bevor- 
zugt ohne weitere Eingriffe auf den jeweils nachf olgenden Cotn- 
pilern verarbeitbar . Gegebenenf alls konnen Compil erf lags und 
Constraints zur Steuerung nachf olgender Compiler generiert 
werden, wobei der Anwender falls gewiinscht optional eigene 
Vorgaben hinzufiigen und/oder die generierten Vorgaben modifi- 
zieren kann. Die nachf olgenden Compiler benotigen keine we- 
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sentlichen Modif ikationen, so da& per se bekannte Standard- 
Tools prinzipiell einsetzbar sind. 



Das vorgeschlagene Verfahren eignet sich somit beispielsweise 
insbesondere als Praprozessor bzw. Praprozessorverf ahren vor 
Cotnpilern und Entwicklungssystemen. Es soil aber ausdriicklich 
eirwahnt werden, dafi prinzipiell anstatt und/oder zusammen mit 
den zuvor beschriebenen Ubersetzers auch Compiler nach PACTll 
eingebunden werden konnen. 

An die beschriebene Architektur, insbesondere direkt an die 
VPU kann ein FPGA gekoppelt sein, urn f eingranulare Datenverar- 
beitung zu ermoglichen und/oder ein flexibel adaptierbares In- 
terface (z.B. diverse serielle Schnittstellen (V24, USB, 
etc.), diverse parallele Schnittstellen, Festplattenschnitt- 
stellen, Ethernet, Telekommunikationsschnittstellen (a/b, TO, 
ISDN, DSL, etc) ) zu weiteren Baugruppen zu ermoglichen. 
Der FPGA kann dabei aus der VPU- Architektur, insbesondere 
durch die CT, und/oder durch die CPU konfiguriert werden. Der 
FPGA kann statisch, also ohne Rekonf iguration zur Laufzeit 
und/oder dynamisch, also mit Rekonf iguration zur Laufzeit, be- 
trieben werden. 

Es wurde bereits das Vorsehen eines Interface -Code angespro- 
chen. Der Interface -Code, der in den extrahierten Code einge- 
setzt wird, kann durch unterschiedliche Verfahren vorgegeben 
werden. Bevorzugt wird der Interface-Code in einer Datenbank 
abgelegt, auf die zugegriffen wird. Die Einheit zur Umsetzung 
kann so ausgebildet sein, dalS sie eine Auswahl, etwa des Pro- 
grammierers, beriicksichtigt , bei der beispielsweise durch Hin- 
weise im PROGRAMM oder durch Compilerf lags der passende Inter- 
face-Code ausgewahlt wird. Dabei kann ein fvir das jeweils ver- 
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wendete Implement ierungsverfahren des VPU/ CPU- Systems geeigne- 
ter Interface -Code gewahlt werden.. 



Die Datenbank selbst kann durch unterschiedliche Methoden auf- 
gebaut und gewartet werden. Einige Beispiele sollen zur Ver- 
deutlichung der Moglichkeiten angefiihrt warden: 

a) Der Interface -Code kann vom Lieferanten des Compilers fur 
bestimmte Verbindungsverf ahren zwischen VPU und CPU(s) 
vorgegeben werden. Dies kann bei der Organisation der Da- 
tenbank berucksichtigt werden, indem entsprechende Spei- 
chermittel fiir diese Angaben bereitgehalten werden. 

b) Der Interface -Code kann vom Benutzer, der den Systemaufbau 
bestimmt hat, selbst geschrieben oder aus bestehenden 
(Beispiel-) Interface-Code modifiziert und der Datenbank 
zugefiigt werden. Das Datenbankmittel wird hierzu bevorzugt 
benutzermodifizierbar gestaltet, urn dem Benutzer die Da- 
tenbankmodif ikation zu ermoglichen. 

c) Der Interface -Code kann von eine Entwicklungs system, mit 
dem beispielsweise der Systemaufbau des VPU -CPU -Systems 
geplant und/oder beschrieben und/oder getestet wurde, au- 
tomatisch generiert werden. 

Der Interface-Code ist gewohnlicherweise bevorzugt derart ge- 
staltet, daS er den Anforderungen der Programmiersprache ent- 
spricht, in der der extrahierte Code vorliegt in den der In- 
terface-Code eingefiigt werden soil. 

Debugging und Integration der Toolsets 

In die Interface-Codes k6nnen Kommunikationsroutinen einge-. 
fiihrt werden, urn die unterschiedlichen Entwicklungssysteme fiir 
PROZESSOR und VPU zu synchronisieren. Insbesondere kann Code 
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fur die jeweiligen Debugger (z. B. nach PACTll) aufgenoramen 
werden . 



Der Interface-Code ist so ausgebildet, dafi er den Datenaus- 
tausch zwischen PROZESSOR und VPU ermoglicht und/oder steuert. 
Er ist daher eine geeignete und bevorzugte Schnittstelle, um 
die jeweiligen Entwicklungssysteme und Debugger zu steuern. Es 
ist beispielsweise moglich, einen Debugger f^ir den PROZESSOR 
solange zu aktivieren, wie die Daten von dem Prozessor verar- 
beitet werden. Sobald die Daten uber den Interface -Code an ei- 
ne (Oder mehrere) VPU ubergeben werden, ist ein Debugger fur 
VPUs zu aktivieren. Wird der Code zuriick an den PROZESSOR ge- 
sendet, soil wiederutn der PROZESSOR- Debugger aktiviert werden. 
Es ist daher also moglich und bevorzugt, derartige Ablaufe 
durch das Einfiigen von Steuercodes fur Debugger und/oder Ent- 
wicklungssysteme in den Interface-Code aljzuwickeln . 

Die Kommunikation und Steuerung zwischen den unterschiedlichen 
Entwicklungssystemen soli daher bevorzugt mittels in die In- 
terface-Codes von PROZESSOR und/oder VPU eingebrachte Steuer- 
codes abgewickelt werden. Die Steuercodes k6nnen dabei beste- 
henden Standards fur die Steuerung von Entwicklungssystemen 
weitgehend entsprechen. 

Die Verwaltung und Kommunikation der Entwicklungssysteme wird 
vorzugsweise wie beschrieben in die Interface-Codes abgewik- 
kelt, kann jedoch - sofern sinnvoll - auch getrennt von die- 
sen, nach einem entsprechenden ahnlichen Verfahren abgewickelt 
werden . 

In vielen Programmiersprachen, besonders in sequent iellen wie 

z. B. C, wird eine.exakte zeitliche Reihenfolge implizit durch 

die Sprache vorgegeben. Bei sequent iellen Programmiersprachen 
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geschieht dies beispielsweise durch die Reihenfolge der ein- 
zelnen Anweisungen. Sofern durch Programmiersprache und/oder 
den Algorithmus erf orderlich, laSt sich die Zeitinf ormation 
auf Synchronisationstnodelle wie RDY/ACK und/oder REQ/ACK oder 
ein Time- Stamp -Verfahren abbilden. 

Beispielsweise wird eine nachfolgende for-Schleife nur dann 
durchlaufen und iteriert, wenn eine Variable, hier input stream 
je Durchlauf mit einem RDY quittiert ist. Bleibt RDY aus, wird 
der Schleifendurchlauf bis zum Eintreffen RDY angehalten: 

while TRUE 
S := 0 

for i: 1 to 3 

s := s + inputstream; 

Die Eigenschaft der sequentiellen Sprachen, nur von der Be- 
fehlsverarbeitung gesteuert zu werden, wird mit dem DatenfluS- 
prinzip die Verarbeitung durch den Datenstrom, bzw. die Exi- 
stenz von Daten zu steuem verbunden. Mit anderen Worten wird 
ein Befehl und/oder eine Anweisung (z. B. s := s + 
inputstream;) nur verarbeitet, wenn die Operation ausgefuhrt 
werden kann und die Daten verfiigbar sind. 

Bemerkenswert ist, daS dieses Verfahren gewohnlicherweise zu 
keiner Anderung der Syntax oder Semantik einer Hochsprache 
f uhrt . 

Komplexere Funktionen einer Hochsprache, wie z. B. Schleifen, 
werden durch Makros realisiert. Die Makros werden vom Compiler 
vorgegeben und zur Ubersetzungszeit instantiiert . 
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Die Makros sind entweder aus einfachen Sprachkonstrukten der 
Hochsprache oder auf Assemblerlevel auf gebaut . Makros konnen 
parametriert sein, um eine einfach Adaption an den beschriebe- 
nen Algorithmus zu ertnoglichen . (vgl. auch PACTll) 



Ein Standardprozessor z.B. ein RISC, CISC, DSP (CPU) wird also 
mit einem rekonf igurierbaren Prozessor (VPU) gekoppelt . 

Zwei unterschiedliche, bevorzugt jedoch auch zugleich imple- 
mentierbare Kopplungsvarianten konenn wie folgt beschrieben 
sein. 

Eine erste Variante sieht eine direkte Ankoppelung an den Be- 
fehlssatz einer CPU vor (Bef ehlssatzkopplung) . 
Eine zweite Variante sieht eine Ankoppelung uber Tabellen im 
Hauptspeicher vor. Es sind also Tabellenmittel vorgesehen. 

Innerhalb eines Instruktionssatzes (ISA) einer CPU sind fur 
gewohnlich freie unbenutzte Befehle vorhanden. Einer oder eine 
Mehrzahl dieser freien unbenutzen Befehle wird nuninehr fur die 
Steuerung von VPUs verwendet (VPUCODE) . 

Durch die Dekodierung eines VPUCODEs wird eine Konf igurations- 
einheit (CT) einer VPU angesteuert die in Abhangigkeit des 
VPUCODEs bestimmte. Ablaufe ausfuhrt. Es ist also eine zur VPU- 
Decodierung ansprechbare CT vorhanden. 

Beispielsweise kann ein VPUCODE das Laden und/oder Ausfuhren 
von Konf igurationen durch die Konf igurationseinheit (CT) fiir 
eine VPU auslosen. 
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In einer erweiterten Ausfuhrung kann ein VPUCODE iiber eine 
Ubersetzungstabelle, die bevorzugt von der CPU, alternativ 
aber auch von der oder einer VPU Oder einer externen Einheit 
aus verwaltet wird, auf unterschiedliche VPU-Kommandos iiber- 
setzt werden 

Die Konf igurationstabelle kann in Abhangigkeit von dem ausge- 
fiihrten CPU Programm oder Codeabschnitt gesetzt werden. 

Die VPU ladt nach Eintreffen eines Ladekommandos Konf iguratio- 
nen aus einem eigenen oder mit der CPU geteilten Speicher. 
Insbesondere kann eine VPU- Konf igurat ion ira Code des aktuell 
ausgefuhrten CPU- Programmes beinhaltet sein. 

Nach Erhalt eines Ausf uhrungskommandos fvihrt eine VPU die aus- 
zufuhrende Konf iguration aus und die entsprechende Datenverar- 
beitung durch. Das Beenden der Datenverarbeitung kann durch 
ein Terminierxings signal (TERM) an die CPU angezeigt werden. 
Dazu sind entsprechende Signalleitungen/Interrupt-Eingange 
usw. vorhanden und/oder. ausgebildet . 

Das Auftreten eines VPUCODEs konnen solange Wartezyklen auf 
der CPU ausgefiihrt werden, bis das Terminierungssignal (TERM) 
der Beendigung der Datenverarbeitung von der VPU eintrifft. 

In einer bevorzugten Ausgestaltung wird mit der Verarbeitung 
der nachsten Codes fortgef ahren. Tritt ein weiterer VPUCODE 
auf, kann sodann auf die Beendigung des vorhergehenden gewar- 
tet werden, oder samtliche gestartete VPUCODEs werden in einer 
Verarbeitungspipeline eingereiht, oder ein Taskwechsel wird 
insbesondere wie nachfolgend beschrieben ausgefiihrt. 
Die Beendigung einer Datenverarbeitung wird durch das Eintref- 
fen des Terminierungssignal (TERM) in einem Statusregister si- 
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gnalisiert. Die Terminierungssignale treffen in der Reihenfol- 
ge einer moglichen Verarbeitungspipeline ein. 



Die Datenverarbeitung auf der CPU kann durch das Testen des 
Statusregisters auf das Eintreffen eines Terminierungssignales 
synchronisiert warden. 

In einer moglichen Ausgestaltung kann, sofern eine Applikation 
vor dem Eintreffen von TERM z.B. durch Datenabhangigkeiten 
nicht fortgesetzt werden kann, ein Taskwechsel ausgelost wer- 
den. 

Es ist bevorzugt, wenn lose Kopplungen zwischen. Prozessoren 
und VPUs aufgebaut sind, bei welchen VPUs weitestgehend als 
unabhangige Coprozessoren arbeiten. 

Eine derartige Kopplung sieht eine oder mehrere gemeinsame Da- 
tenquellen und -senken, zumeist iiber gemeinsame Bussysteme 
und/oder gemeinsame Speicher vor, Uber DMAs und/oder andere 
Speicherzugrif f skontroller werden Daten zwischen einer CPU und 
einer VPU ausgetauscht . Die Synchronisation der Datenverarbei- 
tung erfolgt bevorzugt iiber eine Interruptsteuerung oder einen 
Statusabf ragemechanismus (z.B. Polling). 

Eine enge Ankopplung entspricht der vorab beschriebenen direk- 
ten Ankopplung einer VPU in den Befehlssatz einer CPU. 

Bei einer direkten Rechenwerk -Ankopplung ist besonders auf ei- 
ne hohe Rekonf igurationsperformance zu achten. Bevorzugt kann 
daher die Wave -Rekon figuration zutn Einsatz kommen. Desweiteren 
werden die Konf igurationsworte bevorzugt vorab derart vorgela- 

den, dass bei Ausfuhrung des Befehls die Konf iguration beson- 
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ders schnell (mittels Wave-Reconfiguration im Optimalfall in- 
nerhalb eines Taktes) konfiguriert warden kann. Im ubrigen wa- 
re auch moglich, anstelle einer Array-Teilkonf iguration bei 
hoch performanten, insbesondere aber auch bei uberwiegend nie- 
derperformanten Anwendungen mehrere insbesondere identische 
Arrays vorzusehen, von diesen wenigstens eines fiir eine neue 
Task umzukonf igurieren, insbesondere im Vorgriff , und dann 
nach Bedarf anstelle einer Umkonf iguration oder Teilumkonf igu- 
ration eines integralen multidimensionalen partiell zur Laiif- 
zeit rekonf igurierbaren grobgranularen Feldes einfach auf ein 
anderes Array vollstandig zu wechseln. Signale konnen dabei z. 
B. iiber MUX-/Demuxstuf en den Teilarrays zugefuhrt werden, ins- 
besondere I/O-, Daten-, Status- und/oder Triggersignale . 

Fiir die Wave -Reconfiguration werden bevorzugt die voraussicht- 
lich auszufuhrenden Konf igurationen vorab durch den Compiler 
zur Corapilezeit erkannt und zur Lauf zeit entsprechend vorgela- 
den. 

Zum Zeitpunkt der Bef ehlsausfuhrung wird die entsprechende 
Konf iguration gegebenenf alls fiir jede PAE einzeln und/oder fur 
eine PAE-Teilmenge einzeln selektiert und ausgefiihrt. Auch 
derartige Verfahren sind nach den o.g. Schriften bekannt . 

Eine bevorzugte Implementierung kann unterschiedliche Daten- 
transfers zwischen einer CPU und VPU yorsehen. Drei besonders 
bevorzugte einzeln oder kombiniert einsetzbare Methoden werden 
nachfolgend beschrieben. 

Bei einer Registerkopplung kann die VPU Daten aus einem CPU- 
Register entnehmen, verarbeiten und in ein CPU- Register zu- 
ruckschre iben . 
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Bevorzugt werden Synchronisationsmechanismen zwischen der CPU 
und der VPU eingesetzt. 



Beispielsweise kann die VPU durch das Einschreiben der Daten 
in ein CPU-Register durch die CPU ein RDY-Signal erhalten und 
daraufhin die eingeschriebenen Daten verarbeiten. Das Auslesen 
von Daten aus einem CPU-Register durch die CPU kann ein ACK- 
Signal generieren, wodurch die Datenabnahme durch die CPU der 
VPU signalisiert wird. Die Verwendung des per se bekannten 
RDY/ACK-Protokolls in unterschiedlicher Auspragung ist vorlie- 
gend gerade bei grobgranularen Zellen der rekonf igurierbaren 
Einheiten vorteilhaf t . 

CPUs stellen typischerweise keine entsprechenden Mechanismen 
zur Verfugung. 

Zwei mogliche L6sungen werden naher beschrieben: 

Ein einfach zu realsierenden Ansatz ist, die Datensynchronisa- 
tion uber ein Statusregister durchzuf uhren . Beispielsweise 
kann die VPU das erfolgte Auslesen von Daten aus einem Regi- 
ster und das damit verbundene ACK-Signal und/oder das Ein- 
schreiben . von Daten in ein Register und das damit verbundene 
RDY-Signal in dem Statusregister anzeigen. Die CPU testet zu- 
nachst das Statusregister und fuhrt beispielsweise so lange 
Warteschleifen Oder Taskwechsel aus, bis - je nach Operation - 
das RDY Oder ACK eintraf . Danach fiihrt die CPU den jeweiligen 
Registerdatentransfer aus. 

In einer erweiterten Ausgestaltung wird der Befehlssatz der 

CPU urn load/store- Instruktionen mit integrierter Statusabf rage 

(load_rdy, store_ack) erweitert. Beispielsweise. wird bei einem 

store_ack nur dann ein neues Datenwort in ein CPU-Register ge- 
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schrieben, wenn das Register vorher von der VPU ausgelesen 
wurde und ein ACK eintraf . Entsprechend liest load_rdy nur Da- 
ten aus einem CPU-Register, wenn die VPU vorher neue Daten 
eingeschrieben und ein RDY generiert hat. 

Daten, die zu einer auszuf lihrenden Konf iguration gehoren kon- 
nen sukzessive, quasi durch Block-Moves ahnlich wie nach dem 
Stand der Technik in die CPU-Register geschrieben und/oder aus 
diesen gelesen warden. Ggf . implementierte Block-Move- 
Instruktionen konnen bevorzugt durch die beschriebene inte- 
grierte RDY/ACK Statusabf rage erweitert werden. 

Es ist of fensichtlich, dass eine Vielzahl von leichten Modifi- 
kationen und unterschiedlichen Ausgestaltungen dieses Grund- 
verfahrens moglich sind. 

Die bereits erwahnte Wave -Rekonf iguration erlaubt das Starten 
eines neuen VPU-Befehls und der entsprechenden Konf iguration, 
sobald die Operanden des vorhergehenden VPU-Befehls aus den 
CPU-Registern abgenommen wurden. Die Operanden fur den neuen 
Befehl konnen direkt nach Befehlsstart in die CPU-Register ge- 
schrieben werden. 

Entsprechend des Wave -Rekonf iguration-Verfahrens wird die VPU 
successive mit Fertigstellung der Datenverarbeitung des vorhe- 
rigen VPU-Befehls fur den neuen VPU-Befehl umkonf iguriert und 
die neuen Operanden verarbeitet. 

Weiterhin konnen Daten zwischen einer VPU und einer CPU durch 
geeignete Buszugriffe auf gemeinsame Ressourcen ausgetauscht 
werden . 
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Sofern Daten ausgetauscht werden sollen, die kurz zuvor von 
der CPU verarbeitet wurden und daher voraussichtlich noch im 
bevorzugt vorzusehenden Cache der CPU liegen bzw. sofort an- 
schliessend von der CPU verarbeitet werden und daher sinnvol- 
lerweise in den Cache der CPU gelegt werden, werden diese be- 
vorzugt von der VPU aus dem Cache der CPU gelesen, bzw. in den 
Cache der CPU geschrieben. Dies kann durch geeignete Analysen 
weitestgehend vorab zur Compilezeit der Applikation durch den 
Compiler festgestellt und der Binarcode entsprechend generiert 
werden . 

Sofern Daten ausgetauscht werden sollen, die sich voraussicht- 
lich nicht im Cache der CPU befinden bzw. voraussichtlich 
nicht nachfolgend im Cache der CPU benotigt werden, werden 
diese bevorzugt von der VPU direkt vom externen Bus und der 
damit verbundenen Datenquelle (z.B. Speicher, Peripherie) ge- 
lesen, bzw. an den externen Bus und der damit verbundenen Da- 
tensenke (z.B. Speicher, Peripherie) geschrieben. Dies kann 
durch geeignete Analysen weitestgehend vorab zur Compilezeit 
der Applikation durch den Compiler festgestellt und der Binar- 
code entsprechend generiert werden. 

Bei einem Transfer iiber den Bus am Cache vorbei wird bevorzugt 
ein Protokoll zwischen Cache und Bus implementiert , das fur 
einen korrekten Inhalt des Caches sorgt . Beispielsweise kann 
das bekannte MESI -Protokoll nach dem Stand der Technik hierzu- 
verwendet werden. 

Die beschriebenen Verfahren mussen zun^chst keinen besonderen 
Mechanismus fur die Unterstutzung von Betriebssystemen vorse- 
hen. Es ist namlich bevorzugt, sicherzustellen, dass ein aus- 
zufuhrendes Betriebssystem sich entsprechend des Status einer 
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2U unterstutzenden VPU verhalt, was moglich ist und wozu ins- 
besondere Scheduler vorgesehen sein konnen. 



Bei einer engen Rechenwerkkopplung wird bevorzugt das Status - 
register der CPU abgefragt, in welches die angekoppelte VPU 
ihren Datenverarbeitungsstatus (Tearminierungssignal) eintragt. 
Soil eine weitere Datenverarbeitung an die VPU iibertragen wer- 
den, und die VPU hat die vorherige Datenverarbeitung noch 
nicht beendet wird gewartet und/oder bevorzugt ein Taskwechsel 
ausgefuhrt . 

Fur eine Coprozessorkopplung werden bevorzugt uber das Be- 
triebs system, i.b. den Scheduler gesteuerte Mechanismen ver- 
wendet : 

Ein einfacher Scheduler kann nach Ubertragung einer Funktion 
auf eine VPU entweder den aktuellen Task auf der CPU weiter- 
laufen lassen, sofern dieser unabhangig und parallel zur Da- 
tenverarbeitung auf einer VPU ablaufen kann. Sofern Oder so- 
bald der Task auf die Beendigung der Datenverarbeitung auf der 
VPU warten muss, schaltet der Taskscheduler auf einen anderen 
Task urn. 

Jeder neu aktivierte Task wird, sofern er die VPU verwendet, 
vor Verwendung priifen, ob diese fiir eine Datenverarbeitung zur 
Verfiigung steht und/oder aktuell noch Daten verarbeitet ; dann 
soli entweder auf die Beendigung der Datenverarbeitung gewar- 
tet Oder bevorzugt der Task gewechselt werden. 

Ein einf aches und dennoch leistungsf ahiges Verfahren kann 
durch sogenannte Descriptor Tables aufgebaut werden, die be- 
spielsweise f olgendermafien realisiert werden konnen: 
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Jeder Task generiert zum Aufruf der VPU eine Oder mehrere Ta- 
belle{n) (VPUCALL) mit einem geeigneten festgelegten Datenfor- 
mat in dem ihm zugewiesenen Speicherbereich. Diese Tabelle be- 
einhaltet samtliche Steuerinfoirmation fur eine VPU, wie z.B. 
das auszufuhrende Programm / die auszufiihrende Konf iguration 
und/oder Zeiger auf die Speicherstelle (n) oder Datenquellen 
der Eingangsdaten und/oder die Speicherstelle (n) oder Daten- 
senken der Ergebnisdaten und/oder weitere Ausfiihrungsparame- 
ter , z.B. Datenarraygrofien . 

Im Speicherbereich des Betriebssystems befindet sich eine Ta- 
belle Oder verkettete Liste (LINKLIST) , die auf samtliche 
VPUCALL -Tabe lien in der Reihenfolge ihrer Erstellung zeigt . 

Die Datenverarbeitung auf der VPU ISuft nxinmehr derart ab, 
dass ein Task einen VPUCALL erstellt und uber das Betriebssy- 
stem die VPU auf ruf t . Das Betriebssystem erstellt einen Ein- 
trag in der LINKLIST. Die VPU arbeitet die LINKLIST ab und 
fuhrt die jeweils ref erenzierten VPUCALL aus. Die Beendigung 
einer der jeweiligen Datenabarbeitung wird jeweils durch einen 
entsprechenden Eintrag in die LINKLIST und/oder VPUCALL Tabel- 
le angezeigt . 

Die VPU arbeitet somit weitgehend unabhangig von der CPU. Das 
Betriebssystem und/oder die jeweiligen Task miissen lediglich 
die Tabellen (LINKLIST bzw. VPUCALL) uberwachen. 

Besonders perf ormanceef f izient arbeiten die beiden Verfahren, 
wenn als VPU eine Architektur zum Einsatz kommt, die eine mit 
der Datenverarbeitung uberlagerte und/oder liberlagerbare Re- 
konf iguration zulasst. 
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Damit ist es moglich, eine neue Datenverarbeitung und eine 
ggf . damit verbundene Rekonf iguration sofort nach Lesen der 
letzten Operanden aus den Datenquellen zu starten. Mit anderen 
Worten ist fur die Synchronisation nicht mehr das Beenden der 
Datenverarbeitung, sondern das Lesen der letzten Operanden er- 
forderlich. Dadurch wird die Performance der Datenverarbeitung 
erheblich gesteigert . 

inen zusatzlichen EinfluB auf die Betrachtung und den Umgang 
mit Zustanden hat der mSgliche Einsatz eines Betriebssystemes . 
Betriebssysteme verwenden beispielsweise Task-Scheduler zum 
Verwalten mehrere Aufgaben (Tasks) , urn ein Multitasking zur 
Verftigung zu stellen. 

Task-Scheduler brechen Tasks zu einem bestimmten Zeitpunkt ab, 
starten andere Tasks und kehren nach deren Abarbeitung zur 
Weiterbearbeitung des abgebrochenen Tasks zuriick. 
Sofern sichergestellt ist, daB eine Konf iguration - die der 
Abarbeitung eines Tasks entspricht - nur nach der kompletten 
Abarbeitung - d.h. wenn alle innerhalb dieses Konf igurations- 
zyklusses zu bearbeitende Daten und ZustSnde gespeichert sind 
- terminiert, kOnnen lokal relevante Zusteinde ungespeichert 
bleiben. 

Sofern der Task-Scheduler allerdings Konf igurationen vor deren 
vollstandiger Abarbeitung abbricht, miissen lokale Zustande 
und/oder Daten gespeichert werden. Weiterhin ist dies von Vor- 
teil, wenn die Abarbeitungszeit einer Konf iguration nicht vor- 
hergesagt werden kann. In Verbindung mit dem bekannten Halte- 
problem und dem Risiko, daJi eine Konf iguration (z.B. durch ei- 
nen Fehler) gar nicht terminiert, erscheint dies weiterhin 
sinnvoll, urn damit einen Deadlock des gesamten Systems zu ver- 
hindern . 

Mit anderen Worten sind, unter Berticksichtung von Taskwech- 
seln, relevante Zustande auch als solche anzusehen, die fiir 
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einen Taskwechsel und ein erneutes korrek.es Aufsetzen der Da- 
tenverarbeitung notwendig sind. 

Bei einem Taskswitch ist somit der Speicher fur Ergebnisse und 
ggf . auch der Speicher fiir die Operanden zu sichern und zu ei- 
nem spateren Zeitpunkt, also bei der Ruckkehr zu diesem Task, 
wieder herzustellen. Dies kann vergleichbar zu den PUSH/POP 
Befehlen und Verfahren nach dem Stand der Technik erfolgen. 
Weiterhin ist der Zustand der Datenverarbeitung zu sichern, 
also der Zeiger auf die zuletzt vollstandig bearbeiteten Ope- 
randen. Es sei hier besonders auf PACT18 verwiesen. 

Abhangig von der Optimierung des Taskswitches gibt es bei- 
spielsweise zwei Moglichkeiten: 

a) Die abgebrochene Konf iguration wird neu konfiguriert und 
nur die Operanden werden geladen. Die Datenverarbeitung be- 
ginnt von neuem, als ob die Bearbeutung der Konf iguration noch 
gar nicht begonnen wurde. Mit anderen Worten werden einfach 
alle Datenberechnungen von vorne an ausgefiihrt, wobei ggf. Be- 
rechnungen bereits zuvor durchgefiihrt wurden. Diese Moglich- 
keit ist einfach aber nicht sehr effizient. 

b) Die abgebrochene Konf iguration wird neu konfiguriert, wobei 
die Operaden und bereits berechneten Ergebnisse in die jewei- 
ligen Speicher geladen werden. Die Datenverarbeitung wird bei 
den Operanden fortgesetzt die nicht mehr vollstandig berechnet 
wurden. Dieses Verfahren ist sehr viel effizienter, setzt aber 
voraus, dafi ggf. zusatzliche Zustfinde die wahrend der Verar- 
beitung der Konf iguration entstehen relevant werden, bei- 
spielsweise mufi zumindest ein Zeiger auf die zuletzt vollstan- 
dig verechneten Operanden gesichert werden, damit bei deren 
Nachfolgern nach erfolgter neuer Konf iguration neu aufgesetzt 
werden kann. 

Eine besonders bevorzugte Variante zur Verwaltung von relevan- 
ten Daten wird durch den nachfolgend beschriebenen Kontext 
Switch zur Verfugung gestel.lt. Bei Task-Wechseln und/oder bei 
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der Ausfuhrung von Konf igurationen und derein Wechsel (siehe 
beispielsweise Patentanmeldung PACT15, die zu Of f enbarungs- 
zwecken vollumf Snglich eingegliedert ist) kann es erforderlich 
sein, Daten Oder Zustande, die typischerweise nicht zusammen 
mit den Arbeitsdaten in die Speicher abgelegt werden, da sie 
beispielsweise lediglich einen Endwert markieren, fur eine 
nachfolgende Konf iguration zusichern. 

Der erf indungsgemafie Kontext Switch wird derart durchgefuhrt, 
dass eine erste Konfiguration entfernt wird, die zu sichernden 
Daten verbleiben in den entsprechenden Speichern (REG) (Spei- 
cher, Register, Zahler, etc) . 

Eine zweite Konfiguration wird geladen, diese verbindet die 
REG in geeigneter Weise und definierter Reihenfolge mit einem 
Oder mehreren globalen Speicher (n). 

Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf den/die globalen Speicher zuzugreifen. 
Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden vim auf als Speicher ausgestaltete REG zuzugreifen. 
Entsprechend der konf igurierten Verbindung zwischen den REG 
werden die Inhalte der REG in einer definierten Reihenfolge in 
den globalen Speicher geschrieben, wobei die jeweiligen Adres- 
sen von Adressgeneratoren vorgegeben werden. Der Adressgenera- 
tor generiert die Adressen fiir den/die globalen Speicher (n) 
derart, dass die beschriebenen Speicherbereiche (PUSHAREA) der 
entfernten ersten Konfiguration eindeutig zugeordnet werden 
konnen . 

Mit anderen Worten, es sind bevorzugt fiir unterschiedliche 
Konf igurationen unterschiedliche Adressenraume vorgesehen. Die 
Konfiguration entspricht einem PUSH gewohnlicher Prozessoren. 

Danach verwenden andere Konf igurationen die Ressourcen. 

Die erste Konfiguration soil wieder gestartet werden. Zuvor 
wird eine dritte Konfiguration gestartet, die die REG der er- 
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sten Konf iguration in einer definierten Reihenfolge miteinan- 
der verbindet. 

Die Konf iguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf den/die globalen Speicher zuzugreifen. 

Die Konf iguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf als Speicher ausgestaltete REG zuzugreifen. 

Ein Adressgenerator generiert Adressen derart, dass ein kor- 
rekter Zugriff auf die der ersten Konf iguration zugeordnete 
PUSHAREA erfolgt. Die generierten Adressen und die konfigu- 
rierte Reihenfolge der REG sind derart, dass die Daten der REG 
in der urspriinglichen Ordnung aus den Speichern in die REG ge- 
schrieben werden. Die Konf iguration entspricht einem POP ge- 
wohnlicher Prozessoren. 

Die erste Konf iguration wird wieder gestartet. 

ZusanunengefaBt wird ein Kontext Switch derart durchgefUhrt , 
dass durch das Laden besonderer Konf igurationen, die ahnlich 
von PUSH/POP bekannter Prozessorarchitekturen arbeiten, die zu 
sichernden Daten mit einem globalen Speicher ausgetauschen 
werden . 

Die Funktion soli in einem Beispiel verdeutlicht werden: 

Eine Funktion addiert 2 Zahlenreihen, die LSnge der Reihen ist 

zur Obersetzungszeit nicht bekannt, sondern erst zur Laufzeit. 

proc example 

while Klength do 
x[i] = a[i] + b[i] 

Die Funktion wird nun wahrend ihrer Ausfuhrung unterbrochen, 

beispielsweise durch einen Task-Switch oder well der fur x 
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vorgesehene Speicher voll ist. a,b,x befinden sich zu diesem 
Zeitpunkt erf indungsgemaB in Speichern. i und ggf. length mus- 
sen jedoch gesichert werden. 

Dazu wird die Konf iguration example terminiert, wobei die Re- 
gisterinhalte erhalten bleiben und eine Konf iguration push ge- 
startet, die i und length aus den Registern liest und in einen 
Speicher schreibt. 

proc push 

mem[<push_adr_example>] = i 
push_adr_exajnple++ 
niem[<push_adr_exainple>] = length 

Nach der Ausfahrung wird push terminiert und die Registerin- 
halte konnen gel5scht werden. 

Andere Konf igurationen werden ausgefiihrt. Nach einiger Zeit 
wird die Konf iguration example wieder gestartet. 
Zuvor wird eine Konf iguration pop gestartet, die die Registe- 
rinhalte wieder aus dem Speicher liest. 

proc pop 

i = mem[<push_adr__example>] 

push_adr_example++ 

length = mem[<push_adr_exaraple>] 

Nach der Ausfiihrung wird pop terminiert und die Registerinhal- 
te bleiben bestehen. Die Konf iguration example wird wieder ge- 
startet 

Beschreibung der Figuren 

Figur 1 verdeutlicht ein Beispiel das vorgeschlagene Verfahren 
und zeigt einen moglichen Systemaufbau . Dabei ist ein PROZES- 
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SOR (0101) iiber ein geeignetes Interface (0102) zum Daten- und 
Status -austausch mit einer VPU (0103) verbunden. 
Ein PROGRAMM - Code (0110) wird (z. B. durch einen Praprozessor 
fur einen Compiler) beispielsweise gemaS den beschriebenen Ex- 
traktionstnethoden in einen fiir den PROZESSOR geeigneten Teil 
(0111) und einen VPU-geeigneten Teil (0112) zerlegt. 

0111 wird durch einen dem PROGRAMM-Code entsprechenden Stan- 
dard Compiler (0113) iibersetzt, wobei zuvor der zusatzliche 
Code zur Beschreibung und Verwaltung des Interfaces (0102) 
zwischen dem PROZESSOR und einer VPU aus einer Datenbank 
(0114) eingefugt wird. Auf 0101 ausfiihrbarer sequentieller 
Code wird generiert (0116) und sofern notwendig die entspre- 
chende Programmierung (0117) des. Interfaces (0102) . 

Der Standard -Compiler kann dergestalt sein, dafi er als 
marktubliches Werkzeug oder im Rahraen einer marktublichen Ent- 
wicklungsumgebung vorliegt. Der Praprozessor und/oder mogli- 
cherweise der VPU- Compiler und/oder m6glicherweise der Debug- 
ger und weitere Werkzeuge konnen beispielsweise in eine beste- 
hende marktubliche Entwicklungsumgebung integriert werden. 

0112 wird durch einen VPU Compiler (0115) iibersetzt, wobei zu- 
satzlicher Code zur Beschreibung und Verwaltung des Interfaces 
(0102) aus einer Datenbank (0114) eingefugt wird. Auf 0103 
ausfiihrbare Konf igurationen werden generiert (0118) und sofern 
notwendig die entsprechende Programmierung (0119) des Interfa- 
ces (0102) . Es soil ausdriicklich erwahnt werden, daS prinzipi- 
ell auch Compiler nach DE 101 39 170.6 fur 0115 verwendet wer- 
den kdnnen. 

In Figur 2 ist beispielhaft ein prinzipieller Ablauf einer 
Compilation dargestellt . Ein PROGRAMM (0201) wird in der Ex- 
traktionseinheit (0202) nach unterschiedlichen Verfahren in 
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VPU-Code (0203) und PROZESSOR-Code (0204) zerlegt. Unterschied- 
liche Methoden konnen in beliebiger Kombination zur Extraktion 
angewendet werden, beispielsweise Hinweise im urspriinglichen 
PROGRAMM (0205) und/oder Unterprogrammauf ruf e (0206) und/oder 
Analyseverfahren (0207) und/oder eine Verwertung von objekt- 
orientierten Klassenbibliotheken (0206a) . Der jeweils extra- 
hierte Code wird ggf. ubersetzt und ggf . auf seine Eignung fur 
das jeweilige Zielsystem hin uberpruft (0208) . Dabei ist eine 
Riickkopplung (0209) auf die Extraktion moglich, urn Verbesse- 
rungen durch eine geanderte Zuordnung der Codes zu einem PRO- 
ZESSOR Oder einer VPU bzw. einer Vielzahl derselben zu erhal- 
ten. 

Danach (0211) wird 0203 durch den Interface-Code aus einer Da- 
tenbank (0210) erweitert (0212) und/oder 0204 wird durch den 
Interface- Code aus 0210 zu 0213 erweitert. 

Der entstandene Code wird auf seine Performance analysiert 
(0214), ggf. ist eine Ruckkopplung (0215) auf die Extraktion 
moglich, um Verbesserungen durch eine geanderte Zuordnung der 
Codes zum PROZESSOR Oder einer VPU zu erhalten. 

Der entstandene VPU-Code (0216) wird fvir eine weitere Uberset- 
zung an einen nachgeschalteten fiir die VPU geeigneten Compiler 
weitergegeben. Der entstandene PROZESSOR-Code (0217) wird fur 
die weitere Ubersetzung in einem beliebigen nachgeschalteten 
fur den PROZESSOR geeigneten Compiler weiterverarbeitet . 

Es soil angemerkt werden, dafi einzelne Schritte je nach Ver- 
fahren ausgelassen werden konnen. Wesentlich ist, dalS ein zu- 
mindest weitgehend kompletter und ohne, wenigstens ohne signi- 
fikanten Eingriff durch den Programmierer direkt ubersetzbarer 
Code an jeweils nachgeschaltete Compilersysteme ausgegeben 
wird. 
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Es wird demnach vorgeschlagen, daE ein Praprozessormittel mit 
einem Codeeingang fur die Einspeisung von zu compilierendem 
Code, mit Codeanalysemitteln, insbesondere Codestruktur 
und/oder Datenformat- und/oder Datenstroms-Erkennungs- 
und/oder Bewertungsmitteln sowie mit einem Auf teilungsbewer- 
tungsmittel zur Bewertung einer im Ansprechen auf Signale aus 
dem Codeanalysemittel vorgenommenen Codeauf teilung sowie gege- 
benenfalls einem Iterationsmittel zur Wiederholung einer Code- 
aufteilung bis zum Erreichen stabiler und/oder hinreichend ak- 
zeptabler Werte mit zumindest zwei Teilcodeausgangen versehen 
ist, wobei ein erster Teilcodeausgang Teilcode fur zumindest 
einen herkommlichen Prozessor ausgibt, und wenigstens ein wei- 
terer Teilcodeausgang zur Abarbeitung mit rekonf igurierbaren 
Logikeinheiten, insbesondere mehr- bzw. multidimensionale ins- 
besondere Zellstrukturen aufweisend, insbesondere grobgranula- 
re datenverarbeitende und/oder Logikzellen (PAEs) mit Rechen- 
werken und dergleichen sowie ggf . zugeordneten Registermitteln 
und/oder f eingranularen Steuer- und/oder Kontrollmitteln wie 
Zustandsmaschinen, RDY/ACK-Trigger- und Kommunikationsleitun- 
gen usw bestimmten Code ausgibt. Beide Teilcodeausgange konnen 
in multiplexweise seriell auf einem physikalischen Ausgang 
liegen. 

Die Datenbank fur die Interface-Codes (0210) wird unabh^ngig 
und vor dem Compilerdurchlauf auf gebaut . Beispielsweise sind 
folgende Que lien fur die Datenbank moglich: Vom Lieferanten 
vorgegeben (0220) , vom Benutzer programmiert (0221) oder auto- 
matisch von einem Entwicklungssystem generiert (0222) . 

Der Aufbau einer besonders bevorzugten VPU ist in Figur 3 dar- 
gestellt. Vorzugsweise hierarchische Konf igurationsmanager 
(CT's) (0301) steuern und verwalten eine Anordnung von rekon- 
f igurierbaren Elementen (PACs) (0302). Den CT's ist ein. loka- 
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ler Speicher fur die Konf igurationen zugeordnet (03 03) . Der 
Speicher verfugt weiterhin iiber ein Interface (03 04) zu einem 
globalen Speicher, der die Konf igurationsdaten zur Verfiigung 
stellt. Uber ein Interface (0305) sind die Konf igurationsab- 
lauft steuerbar. Ein Interface der rekonf igurierbaren Elemente 
(0302) zur Ablauf steuerung und Ereignisverwaltung (0306) ist 
vorhanden, ebenso ein Interface zum Datenaustausch (0307) . 

Figur 4 zeigt einen Ausschnitt aus einem beispielhaf ten CPU 
System, beispielsweise einem DSP des Types C6000 von Texas In- 
struments (0401) . Dargestellt sind Programmspeicher (0402) , 
Datenspeicher (0403) , beliebige Peripherie (0404) und EMIP 
(0405) . liber einen Speicherbus (0406) und einem Peripheriebus 
(0407) ist eine VPU als Coprozessor integriert (0408) . Ein 
DMA-Kontroller (EDMA) (0409) kann beliebige DMA- Transfers, 
beispielsweise zwischen Speicher (0403) und VPU (0408) oder 
Speicher (0403) und Peripherie (0404) durchf tihren . 

Figur 5 zeigt eine abstraktere Systemdef inition. Einer CPU 
(0501) ist Speicher (0502) zugeordnet auf den diese schreiben- 
den und/oder lesenden Zugriff besitzt. Eine VPU (0503) ist mit 
dem Speicher gekoppelt. Die VPU ist in einen CT-Teil (0509) 
und die rekonf igurierbaren Elemente zur Datenverarbeitung 
(0510) untergliedert . 

Zur Steigerung der Speicherzugrif f e kann der Speicher mehrere 
unabhangige Zugrif fsbusse aufweisen (multiport) . In einer be- 
sonders bevorzugten Ausgestaltung ist der Speicher in mehrere 
unabhangige Segmente (Speicherbanks) segmentiert, wobei auf 
jede Bank unabhangig zugrif fen warden kann. Samtliche Segmente 
liegen vorzugsweise innerhalb eines einheitlichen Adressraums. 
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Vorzugsweise steht ein Segment hauptsachlich fur die CPU zur 
VerfOgung (0504), ein weiteres Segment steht hauptsachlich fur 
die Datenverarbeitung der VPU zur Verfugung (0505), ein weite- 
res Segment steht hauptsachlich fiir die Konf igurationsdaten 
der VPU zur Verfugung (0506) . 

Typischerweise und bevorzugt weist eine vollausgestaltete VPU 
eigene Adressgeneratoren und/oder DMAs auf urn Datentransf ers 
durchzuf uhren . Alternativ und/oder zusatzlich ist es moglich, 
dass ein DMA (0507) innerhalb des Systems (Fig. 5) fvir Daten- 
transf ers mit der VPU vorgesehen ist. 

Das System enth§lt 10 (0508) auf die CPU und VPU Zugriff haben 
konnen . 

Sowohl CPU als auch VPU konnen jeweils dedizierte Speicherbe- 
reiche und lO-Bereiche aufweis.en, auf die der jeweils andere 
keinen Zugriff hat . 

Ein Datensatz (0511) der im Speicherbereich und/oder im 10- 
Bereich und/oder partiell in einem von beiden liegen kann wird 
zur Kommunikation zwischen CPU und VPU verwendet, z.B. zum 
Austausch von Basisparametern und Steuerinf orraation. Der Da- 
tensatz kann beispielsweise folgende Information beeinhalten: 

1 . Basisadresse (n) des CT-Speicherbereiches in 0506 zur Lo- 
kalisierung der Konf igurationen . 

2. Basisadresse (n) von Datentransf ers mit 0505. 

3. 10 Adressen von Datentransf ers mit 0508. 

4 . Synchronisationsinformation, z.B. Zurucksetzen, anhalten, 
starten der VPU- 

5. Status information der VPU, z.B. Fehler oder Zustand der 
Da t en ve ra rbe i t ung . 
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Die Synchronisation der CPU und VPU erfolgt durch Polling von 
Daten und/oder bevorzugt durch Interruptsteuerung (0512) . 



Figur 6 zeigt eine mogliche Ausgestaltung der Interf acestruk- 
tur einer VPU zur Einbindung in ein System ahnlich Figur 5. 
Dazu warden der VPU ein Speicher/DMA- und/oder lO- Interface 
zum Datentransfer zugeordnet (0601) , ein weiteres System- 
Interface (0602) tibernimmt die Ablauf steuerung wie z.B. das 
Verwalten von Interrupts, das Starten/Stoppen der Verarbei- 
tung, Austausch von Fehlerzustanden, etc. 

Das Speicher/DMA- und/oder lO- Interface wird an einen Spei- 
cherbus und/oder lO-Bus angeschlossen. 

Das System- Interf ace wird vorzugsweise an einen lO-Bus ange- 
schlossen, kann jedoch alternativ oder zusatzlich entsprechend 
0511 auch an einen Speicher angeschlossen sein. 

Die Interfaces (0601, 04 02) konnen zur Anpassung von unter- 
schiedlichen Arbeitsf requenzen von CPU und/oder VPU und/oder 
System ausgestaltet sein, beispielsweise kann das System bzw. 
die CPU mit zB derzeit 500MHz und die VPU mit 200MHz arbeiten. 

Die Interfaces k6nnen eine. Ubersetzung der Busprotokolle 
durchfiihren, beispielsweise kann das VPU interne Protokoll auf 
ein externes AMBA-Busprotokoll umgesetzt werden. Sie bewirken 
also Busprotokolliibersetzungsmittel und/oder sind fiir die Bus- 
protokollubersetzung ausgebildet, insbesondere die Busproto- 
kolliibersetzung zwischen internem VPU- Protokoll und bekanntem 
Busprotokoll . Es ist auch moglich, eine Konvertierung direkt 
auf CPU- interne Busprotokolle vorzusehen. 

Das Speicher/DMA- und/oder lO- Interface unterstiitzt den Spei- 
cherzugriff der CT auf einen externen Speicher, der vorzugs- 
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weise direkt (memory mapped) erfolgt. Der Datentransf er der 
CT(s> und/oder PAC(s) kann gepuffert z.B. uber FIFO-Stufen er- 
folgen. Extemer Speicher kann direkt angesprochen und adres- 
siert werden, weiterhin konnen DMA interne \ind/oder externa 
DMA- Transfers durchgefuhrt werden. 

Uber das System- Interface erfolgt die Steuerung der Datenver- 
arbeitung, wie beispielsweise die Initialisierung und/oder der 
Start von Konf igurationen. Des weiteren werden Status und/oder 
Fehlerzustande ausgetauscht . Interrupts fur die Steuerung und 
Synchronisation zwischen den CT's und einer CPU konnen unter- 
stutzt werden. 

Das System- Interface kann VPU- interne Protokolle derart kon- 
vertieren, dass diese auf externe (Standard) -Protokolle umge- 
setzt werden (z.B- AMBA) . 

Ein bevorzugtes Verfahren zur Codegenerierung fur das be- 
schriebene System ist in anderen Teilen dieser Anmeldung be- 
schrieben. Das Verfahren beschreibt einen Compiler, der Pro- 
grammcode in Code fiir eine CPU und Code fur eine VPU zerteilt. 
Nach unterschiedlichen Verfahren wird die Zerlegung auf die 
unterschiedlichen Prozessoren durchgef \ihrt . In einer besonders 
bevorzugten Ausfuhrung werden dabei die jeweiligen zerlegten 
Codes urn die Interface -Rout inen zur Kommunikation zwischen. CPU 
und VPU erweitert- Die Erweiterung kann automatisch durch den 
Compiler erfolgen. 

Die nachfolgende Tabellen zeigen beispielhaf te Kommunikationen 
zwischen einer CPU und einer VPU. Den Spalten sind die jewei- 
lig aktiven Funktionseinheiten zugeordnet: CPU, System-DMA .und 
DMA-Interface (EDMA) bzw. Speicher- Interface (Speicher-I/P) , 
System- Interface (System- I./F, 0602), CT's, sowie die PAC. In 
den Zeilen sind die einzelnen Zyklen in ihrer Ausfuhrungsrei- 
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henfolge eingetragen. Kl referenziert sine aus zuf uhr ende Kon- 
figuration 1. 



Die erste Tabelle zeigt beispielsweise einen Ablauf bei Ver- 
wendung der System-DMA (EDMA) zura Datentransf er : 



CPU 


EDMA 


System- I/F 


CT's 


PAC 


Initiiere 
Kl 












Lade Kl 








Starte Kl 






Konf igurie- 
re Kl 




Initiiere 
laden der 
Daten per 
EDMA 




Starte Kl 




Warten auf 
Daten 


lesen der 
Daten per 
EDMA 


Da t ent rans ~ 
far lesen 
der Daten 






Datenver- 
arbeitung 




Dat ent rans - 
fer schrei- 
ben der Da- 
ten 


Signalisie- 
re Ende der 
Operation 







Es ist zu erwahnen, dass die Synchronisation zwischen der EDMA 
und der VPU automatisch uber das Interface 04 01 erfolgt, d.h. 
DMA-Tranfers finden nur statt, wenn die VPU dafur bereit ist. 

In einer zweiten Tabelle ist beispielsweise ein bervorzugter 
optimierter Ablauf dargestellt. Die VPU besitzt selbst direk- 
ten Zugriff auf den Konf igurationsspeicher (0306) . Desweiteren 
werden die Datentransf ers durch DMA-Schaltung innerhalb der 
VPU ausgefuhrt, die beispielsw-ise fest implementiert sein 
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konnen und/oder durch die Konf iguration von konf igurierbaren 
Teilen der PAC entstehen. 



CPU 


EDMA 


System- I/F 


CT ' s 


PAC 


Initiiere 
Kl 










Starte Kl 


Lesen der 
Konf igurati- 
on 




Konf igurie- 
re Kl 






Datentrans- 
fer lesen 
der Daten 


Starte Kl 




Lese Daten 










Datenver- 
arbeitung 




Datentrans- 
fer schrei- 
ben der Da- 
ten 


Signalisie- 
re Ende der 
Operation 




Schreibe 
Daten 



Der Auf wand f iir die CPU ist minimal - 

Zusammenfassend befaSt sich die vorliegende Erfindung mit Ver- 
fahren, die eine Ubersetzung einer klassischen Hochsprache wie 
Pascal, C, C++, Java, etc. auf eine rekonf igurierbare Archi- 
tektur ermoglicht. Das Verfahren ist derart ausgelegt, dafi nur 
die jeweils fur die rekonf igurierbare Zielarchitektur geeigne- 
ten Telle des zu iibersetzenden Programmes extrahiert werden. 
Die verbleibenden Telle des Programmes werden auf eine konven- 
tionelle Prozessorarchitektur ubersetzt. 

In Figur 7 sind aus Grunden der Ubersichtlichkeit nur die re- 
levanten Komponenten (i.b. der CPU) aufgezeigt sind, wobei ty- 
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pisch eine wesentliche Zahl weiterer Komponenten und Netzwerke 
vorhanden sein wird. 



Eine bevorzugte Impleraentierung wie beispielsweise in Figur 1 
dargestellt kann unterschiedliche Datentransf ers zwischen ei- 
ner CPU (0701) und VPU (0702) vorsehen. Die auf der VPU auszu- 
fuhrenden Konf igurationen werden durch den Instruktionsdekoder 
(0705) der CPU selektiert, der bestimmte fiir die VPU bestimmte 
Instruktionen erkennt und die CT (0706) derart ansteuert, dass 
diese die entaprechenden Konf igurationen aus einem der CT zu- 
geordneten Speicher (0707) - der insbesondere mit der CPU ges- 
hared werden oder derselbe wie der Arbeitsspeicher der CPU 
sein kann, in das Array aus PAEs (PA, 0108) ladt . 

Es Bind CPU- Register (0703) vorgesehen, um bei einer Register- 
kopplung Daten zu entnehmen, zu verarbeiten und in ein CPU- 
Register zuruckschreiben. b Fiir die Datensynchronisation ist 
ein Statusregister (0704) vorgesehen. Weiter ist ein Cache 
vorgesehen, der dafur vorgesehren ist, daS wenn Daten ausge- 
tauscht werden sollen, die kurz zuvor von der CPU verarbeitet 
wurden, diese voraussichtlich noch im Cache (0709) der CPU 
liegen bzw. sofort anschliessend von der CPU verarbeitet wer- 
den. 

Der externe Bus ist mit (0710) bezeichnet und es werden dar- 
iiber zB aus einer damit verbundenen Datenquelle (z.B. Spei- 
cher, Peripherie) gelesen, bzw. an den externen Bus und der 
damit verbundenen Datensenke (z.B. Speicher, Peripherie) ge- 
schrieben. Dieser Bus kann insbesondere derselbe wie der ex- 
terne Bus der CPU sein (0712 & gestrichelt) . 

Ein Protokoll (0711) zwischen Cache und Bus ist implementiert , 
das fiir einen korrekten Inhalt des Caches sorgt. Mit (0713) 

48 



wo 02/103532 PCT/EP02/06865 
ist ein FPGA (0713) bezeichent, der mit der VPU gekoppelt sein 
kann, um f eingranulare Datenverarbeitung zu ermoglichen 
iind/oder ein flexible adaptierbare Interface (0714) (z.B. di- 
verse serielle Schnittstellen (V24, USB, etc.), diverse paral- 
lele Schnittstellen, Festplattenschnittstellen, Ethernet, Te- 
lekommunikationsschnittstellen (a/b, TO, ISDN, DSL, etc)) zu 
weiteren Baugruppen iind/oder dem externen Bussystera (0712) zu 
ermoglichen. 

Entsprechend Figur 8 befindet sich Speicherbereich des Be- 
triebssystems eine Tabelle oder verkettete Liste (LINKLIST, 
0801) , die auf samtliche VPUCALL-Tabellen (0802) in der Rei- 
henf olge ihrer Erstellung zeigt . 
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Patentanspriiche 

1 . Verf ahren zur tibersetzung von Programmen auf ein System be- 
steherid aus wenigstens einem ersten Prozessor und einer re- 
konf igurierbaren Einheit, dadurch gekennzeichnet , dafi die 
Codeteile, die fiir die rekonf igiarierbare Einheit geeignet 
sind, bestimmt uiid extrahiert und/oder separiert wird, wo- 
bei verbleibender Code zur Abarbeitung durch den ersten 
Prozessor bestimmt wird. 

2. Verf ahren nach Anspjruch 1, dadurch gekennzeichnet, daS dem 
fiir den Prozessor extrahierten Code Interface -Code zugefiigt 
wird, der eine Kommunikation zwischen Prozessor und rekpn- 
f igurierbarer Einheit entsprechend des Systemes ermoglicht. 
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3. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet , daS dem fur die rekonf igurierbarer Einheit 
extrahierten Code solcher Interface-Code zugefiigt wird, der 
eine Kommunikation zwischen Prozessor und rekonf igurierba- 
rer Einheit entsprechend des Systems ermoglicht . 

4. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daS der zu extrahierende Code aufgrund von 
automatisierten Analysen festgelegt wird. 

5. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, dafi Hinweise im Code zur Feststellung des 
zu extrahierenden Code automat isch ausgewertet werden. 

6. Verfahren nach einem der, vorhergehenden Anspruche, dadurch 
gekennzeichnet, dalS der zu extrahierende Code aufgrund von 
Aufrufen von Unterprogrammen festgestellt wird. 

7. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daS ein Interface -Code vorgesehen wird, 
der eine Speicherkopplung (Shared-Memory) vorsieht 
und/oder eine Registerkopplung und/oder eine Kopplung mit- 
tels eines Netzwerkes bewirkt . 

8. Verfahren nach einem der vorhergehenden Anspruche, dadurch 

gekennzeichnet, daS der extrahierte Code und/oder mit einer 
gegebenen Extraktion erzielbaren Resultate analysiert wird 
und gegebenenf alls die Extraktion mit neuen verbesserten 
Parametern erneut gestartet wird. 

9. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, dafi dem extrahierten Code Steuer-Code zur 
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Verwaltung und/oder Steuerung und/oder Kommunikation der 
Entwicklungssysteme zugefugt wird. 



10. Verfahren nach einem der vorhergehenden Anspriiche, worin 
der erste Prozessor eine konventionelle Prozessorarchitek- 
tur aufweist, insbesondere ein Prozessor mit von - Neumann 
- und/oder Harwardarchitektur, Kontroller, CISC-, RISC-, 
VLIW-, DSP-Prozessor . 

11. Verfahren insbesondere nach einem der vorhergehenden An- 
spriiche zur iibersetzung von Programraen auf ein System be- 
stehend aus einem Prozessor und einer rekonf igurierbaren 
Einheit, dadurch gekennzeichnet , dafi die Codeteile, die fur 
die rekonfigurierbare Einheit geeignet sind, extrahiert 
werden, der verbleibende Code derart extrahiert wird, daS 
er mittels eines beliebigen gewohnlichen unmodif izierten 
fUr den Prozessor geeigneten Compilers iibersetzbar ist. 

12. Vorrichtung zur Datenverarbeitung mit wenigstens einem 
herkSmmlichen Prozessor und wenigstens einer rekonfigu- 
rierbaren Einheit, dadurch gekennzeichnet, daS ein Mittel 
zum Informationsaustausch, insbesondere von Daten- und 
Statusinformation, zwischen- herkommlichem Prozessor und 
rekonf igurierbarer Einheit aufweist, wobei das Mittel so 
ausgebildet ist, daS ein Daten- und Statusinformation zwi- 
schen denselben wahrend der Abarbeitung eines oder mehrere 
Programme moglich ist und/oder ohne daS insbesondere die 
Datenverarbeitung auf dem rekonf igurierbaren Prozessor 
und/oder dem herkommlichen Prozessor signif ikant unterbro- 
chen werden muS. 
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